home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 164 < prev    next >
Internet Message Format  |  1996-08-06  |  2KB
  1. Path: lyra.csx.cam.ac.uk!nmm1
  2. From: nmm1@cus.cam.ac.uk (Nick Maclaren)
  3. Newsgroups: comp.std.c
  4. Subject: The temporal scope of undefined behaviour [was Re: atexit() ...]
  5. Date: 23 Jan 1996 10:53:56 GMT
  6. Organization: University of Cambridge, England
  7. Message-ID: <4e2eo4$ogq@lyra.csx.cam.ac.uk>
  8. References: <4dhfja$j50@fg70.rz.uni-karlsruhe.de> <4diicg$i9e@lyra.csx.cam.ac.uk> <TANMOY.96Jan22084309@qcd.lanl.gov> <DLMLL6.A0H@ukpsshp1.serigate.philips.nl>
  9. NNTP-Posting-Host: ursa.cus.cam.ac.uk
  10.  
  11. In article <DLMLL6.A0H@ukpsshp1.serigate.philips.nl>, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
  12. |> 
  13. |> A related question - does undefined behaviour invalidate (make
  14. |> undefined) all defined behaviour that has gone before? If so
  15. |> does this mean that any program that does not exit() or return
  16. |> from main have any defined behaviour?
  17.  
  18. This is a very good question.  I understand the standard to imply
  19. that all previous defined behaviour must have 'occurred', but
  20. there is (in general) no necessity for it to have had an effect
  21. on the outside world (assuming that such a thing exists).  Some
  22. constructions (e.g. fflush()) require effects to be transmitted
  23. to the environment.
  24.  
  25. But many vendors justify poor implementations by defining a most
  26. bizarre 'environment', and then claiming that it is all the fault
  27. of the latter :-(  In other cases, when the underlying system
  28. does not provide appropriate primitives, this excuse is justified.
  29.  
  30.  
  31. An even nastier problem is what happens after a C run-time system
  32. has correctly trapped and recovered from a case of undefined
  33. behaviour (e.g. SIGFPE).  Many or most vendors will use the
  34. weasel words in the standard to refuse to accept ANY bug report
  35. that relates to this area, no matter how obvious the bug is.
  36.  
  37. However, I tried to think of any wording that would handle this
  38. case properly, and failed.  I believe that some of the critical
  39. areas (e.g. signal() and longjmp()) could be improved by adding
  40. more requirements for implementation defined behaviour (instead
  41. of undefined), but that is about all.
  42.  
  43.  
  44. Nick Maclaren,
  45. University of Cambridge Computer Laboratory,
  46. New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
  47. Email:  nmm1@cam.ac.uk
  48. Tel.:  +44 1223 334761    Fax:  +44 1223 334679
  49.